Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New default path for config file #4301

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

New default path for config file #4301

wants to merge 13 commits into from

Conversation

codebien
Copy link
Contributor

@codebien codebien commented Jan 30, 2025

What?

It changes the default path for config file to .config/k6/config.json from the legacy loadimpact version.

It adds two changes:

  • Commands like k6 run that use the consolidated config get now a warning if the a config file is loaded from the legacy path.
  • k6 cloud login and k6 login commands attempt a migration from the old to the new path. They just do a copy of the file keeping the old file available, in this way old versions can still run using the old path and the user can roll back to the previous config file if something doesn't work as expected.

Why?

Check #2508

Related PR(s)/Issue(s)

Closes #2508

@codebien codebien self-assigned this Jan 30, 2025
@codebien codebien changed the base branch from master to config-file-tests January 30, 2025 15:57
Base automatically changed from config-file-tests to master January 31, 2025 14:13
@codebien codebien marked this pull request as ready for review January 31, 2025 15:05
@codebien codebien requested a review from a team as a code owner January 31, 2025 15:05
@codebien codebien requested review from mstoykov, joanlopez, a team and inancgumus and removed request for a team and mstoykov January 31, 2025 15:05
inancgumus
inancgumus previously approved these changes Feb 3, 2025
Copy link
Member

@inancgumus inancgumus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 Feel free to skip my suggestions if they don't make sense.

internal/cmd/config.go Outdated Show resolved Hide resolved
internal/cmd/config.go Outdated Show resolved Hide resolved
internal/cmd/config.go Show resolved Hide resolved
Copy link
Contributor

@joanlopez joanlopez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall it looks mostly fine, except for a few minor things I pointed out during the review.

However, I have the general doubt around when should we warn users and when should we perform the configuration migration. Isn't file disk configuration also used for other commands like run, archive or cloud run?

Why do we only consider it for k6 cloud login?
Do users normally don't store anything beyond cloud configuration? 🤔

}

func readLegacyDiskConfig(gs *state.GlobalState) (Config, error) {
// CHeck if the legacy config exists in the supplied filesystem
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// CHeck if the legacy config exists in the supplied filesystem
// Check if the legacy config exists in the supplied filesystem

Comment on lines 223 to 225
gs.Logger.Warn("The configuration file has been found on the old path. " +
"Please, run again `k6 cloud login` or `k6 login` commands to migrate to the new path. " +
"If you already migrated it manually, then remove the file from the old path.\n\n")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the warning is fine 👌🏻 but I'm not sure whether we should try to use the "new" config file path, if exists, as the default, or not. In such case, we may need to slightly adjust the message.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For instance, some of the scenarios that trigger those doubts in my mind are those in where the new configuration file path exists and is correct, while the old one also exists, but there are issues with them.

In all those cases, an error would be triggered, with no mention to migration. Perhaps too tricky.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm considering to reverse the flow, where we always check the new default before, and only eventually we check the old one. I didn't do that before because the code is a bit tricky in the current version because we are silencing the Not Found error. But I realized it's better to stretch a bit the code to fit it instead of yielding this cognitive load on the user.

return Config{}, errext.WithExitCodeIfNone(err, exitcodes.InvalidConfig)
} else {
gs.Logger.Warn("The configuration file has been found on the old path. " +
"Please, run again `k6 cloud login` or `k6 login` commands to migrate to the new path. " +
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"Please, run again `k6 cloud login` or `k6 login` commands to migrate to the new path. " +
"Please, run again `k6 cloud login` commands to migrate to the new path. " +

As k6 login has been deprecated, I think it's better to not mention it. Right? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a user has a config file because it used k6 login influxdb but they don't have the Cloud they won't be able to migrate anymore. Do you think we should not support them?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmm.. not sure. Let's leave it for now, then. Although I guess that k6 login influxdb will eventually disappear.

}

gs.Logger.Infof("Note, the configuration file has been migrated "+
"from old default path (%q) to the new version (%q).\n\n", legacyFpath, gs.Flags.ConfigFilePath)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"from old default path (%q) to the new version (%q).\n\n", legacyFpath, gs.Flags.ConfigFilePath)
"from the old default path (%q) to the new one (%q).\n\n", legacyFpath, gs.Flags.ConfigFilePath)

@codebien
Copy link
Contributor Author

codebien commented Feb 4, 2025

Hey @joanlopez, thanks for reviewing 👋

However, I have the general doubt around when should we warn users and when should we perform the configuration migration. Isn't file disk configuration also used for other commands like run, archive or cloud run?

I applied mostly what was suggested here #2508 (comment). It makes sense for me because it keeps the same operations' flows. k6 writes the config on k6 login operations, and it reads on all the others. I wouldn't break this principle, so it migrates (write) on k6 login and it warns (reads) on all the others.

In addition, re-reading Ned's comment, I realized I'm applying a reversed logic on the reading path, where we read before the legacy config and only after the new. But there isn't really a requirement for doing it, we can just directly read the new path and only if it doesn't exist then do an additional attempt on the legacy.

Does it make sense for you? The goal here is to provide the best UX so if you have any suggestion to improve it, I'm happy to evaluate them.

@codebien
Copy link
Contributor Author

codebien commented Feb 4, 2025

@inancgumus @joanlopez I have a doubt. During the migration, do you think should we delete the old directories (loadimpact/k6) or should we just leave them there to prevent any additional error?

@inancgumus
Copy link
Member

@codebien

I have a doubt. During the migration, do you think should we delete the old directories (loadimpact/k6) or should we just leave them there to prevent any additional error?

If I understand the approach here correctly, it feels safer and more user-friendly to leave the old directory intact by default. Automatically deleting it can cause unintended data loss or break workflows if the user relies on that directory in ways we haven't anticipated. We can allow users to remove it themselves once they confirm everything works in the new location.

@joanlopez
Copy link
Contributor

In addition, re-reading Ned's comment, I realized I'm applying a reversed logic on the reading path, where we read before the legacy config and only after the new. But there isn't really a requirement for doing it, we can just directly read the new path and only if it doesn't exist then do an additional attempt on the legacy.

Does it make sense for you? The goal here is to provide the best UX so if you have any suggestion to improve it, I'm happy to evaluate them.

Yeah, I think that likely makes more sense. So, we start using the new one, and only use the old one as a fallback, if existing.
And, only in such case, we may try to perform the migration.

@inancgumus @joanlopez I have a doubt. During the migration, do you think should we delete the old directories (loadimpact/k6) or should we just leave them there to prevent any additional error?

Here, I agree with @inancgumus, I'd play safe and just tell the user that we migrated the config, and so they're able to delete the old one manually

@codebien
Copy link
Contributor Author

codebien commented Feb 6, 2025

Hey @inancgumus @joanlopez I've done most of the discussed changes, take another look, please. 🙏
Make sure to test directly building the binary on your machines, as I'm not on OSX then we might discover bugs not visible to me on Linux.

Copy link
Member

@inancgumus inancgumus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 It works on OS X 15.3, too.

@inancgumus inancgumus added this to the v0.57.0 milestone Feb 6, 2025
@codebien codebien modified the milestones: v0.57.0, v1.0.0-rc1 Feb 7, 2025
@joanlopez
Copy link
Contributor

LGTM 👍 It works on OS X 15.3, too.

Also tested on MacOS 15.3 and it also worked for me! 👍🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Change config directory name from "loadimpact" to "k6"
3 participants